Most currently deployed cellular telephone systems conform to either the GSM standards or to the newer 3G standards. Work is ongoing to develop and deploy next generation networks and standards, the foremost of which is the 3GPP's Evolved Packet System (EPS)—also known as Long Term Evolution/System Architecture Evolution (LTE/SAE)—standard. Within EPS, the Evolved Packet Core (EPC) employs the EPS standards and is the replacement for the 2G and 3G packet core known as the General Packet Radio Service (GPRS) core.
FIG. 1 is a simplified illustration of the EPs network architecture. The main components of the EPC are:                MME (Mobility Management Entity): The MME is the key control-node for the LTE access-network. It is responsible for idle mode UE (User Equipment) tracking and paging procedures including retransmissions. Among other tasks, it is involved in the bearer activation/deactivation process and is also responsible for choosing the SGW and the PGW for a UE at the initial attach and the SGW at time of intra-LTE handover involving SGW relocation.        SGW (Serving Gateway): The SGW routes and forwards user data packets, while also acting as the mobility anchor for the user plane during inter-eNodeB (eNB) handovers and as the anchor for mobility between LTE and other 3GPP technologies (terminating the S4 interface and relaying the traffic between 2G/3G systems and a PGW).        PGW (Packet Data Network (PDN) Gateway): The PDN Gateway provides connectivity from the UE to external packet data networks by being the point of exit and entry of traffic for the UE. A UE may have simultaneous connectivity with more than one PGW for accessing multiple PDNs.        
A bearer for a Packet Data Network (PDN) connection spans a number of user plane nodes including the UE, the eNB, the Security Gateway (SeGW) at the border of the operator network, the Serving Gateway (SGW) and the PDN Gateway (PGW). In many cases the path of the traffic over the PDN connection continues from the PGW to an Autonomous System Border Router (ASBR), i.e. one of the operator's border routers constituting a “peering” point with other carriers, and further into the Internet.
When a PDN connection is established, or its path is altered, some or all of the traversed nodes need to be selected (or reselected). Different selection mechanisms are used for different nodes as follows:                The eNB is selected by the UE, governed by radio conditions and guiding parameters in the system information broadcast in the radio access network cells. [An exception is inter-eNB handover, where the source eNB, aided by measurement data from the UE, selects the target cell (and thus target eNB) for the handover.]        The SeGW selection is a consequence of the eNB selection, since the SeGW that the eNB is connected to must be used.        The SGW is selected by the MME.                    The SGW is selected for the default bearer at network “Attach”. A UE can only have a single SGW allocated at a time, so the same SGW is used also for subsequent bearers, irrespective of Access Point Name (APN).            The allocated SGW can be changed due to mobility, e.g. at handover or Tracking Area Update (TAU), in order to optimize the route or because the old SGW does not serve the new eNB. A SGW may serve a limited part of the PLMN's area (i.e. a limited fraction of the eNBs in the PLMN), denoted SGW Service Area (SA). SGW relocation due to fault situations is also possible.                        The PGW is selected by the MME.                    The PGW is selected for the default bearer for a certain APN. A UE can only have a single PGW allocated at a time for a certain APN, so the same PGW is used also for subsequent bearers for the same APN.            A PGW is allocated to the UE for each APN the UE chooses to use for communication (i.e. to establish a bearer for). Hence, a UE can be allocated multiple PGWs, one for each APN.            An allocated PGW is not changed—it remains the same irrespective of mobility for as long as the UE remains attached to the network (for each APN). Hence, each PGW must serve the entire PLMN.                        The ASBR is selected through routing information and policies in the transport network layer and may hence in essence be seen as a consequence of the PGW selection. In a roaming scenario, where the operators of the visited and home PLMNs have established a mutual peering arrangement using a dedicated ASBR, ASBR selection is essentially a consequence of the PLMNs involved. If the two PLMNs have multiple dedicated ASBRs for mutual peering, then the choice among these ASBRs may be a consequence of the PGW selection.        
In general, the various conceivable selection criteria that an MME may consider can be classified into “hard” and “soft” criteria. A hard selection criterion is a criterion that must be fulfilled by the selected node. For example, a selected PGW must support the APN that is associated with the concerned PDN connection and a selected SGW must serve the area (cell/eNB) where the UE is located. A soft selection criterion is a criterion that may or may not be fulfilled. Soft criteria can often be fulfilled to a varying degree—the more the better. Examples that are applicable to both SGW and PGW selection include path optimization (e.g. topological closeness) and load balancing.
SGW/PGW selection takes place in the network whenever a SGW and/or a PGW needs to be allocated to a UE, either to serve a new PDN connection (i.e. a new APN) or to replace a previously allocated SGW. The following are three cases in which SGW/PGW selection is triggered:                Attach (which includes establishment of an initial PDN connection and default bearer). In this selection case both SGW and PGW are selected.        SGW relocation. In this selection case only the SGW is selected, while the PGW(s) remain(s) fixed.        Additional PDN connection establishment (for an additional APN). In this selection case only a PGW is selected, while the already allocated SGW is reused.        
According to presently applicable 3GPP specification TS 29.303 v8.3.0 and TS 23.003 v9.0.0, the mechanisms that the MME can leverage to enable appropriate selections of SGWs/PGWs employ a DNS lookup mechanism and are based on the Straightforward Name Authority Pointer (S-NAPTR) DNS application. S-NAPTR is specified in L. Daigle & A. Newton, “Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)”, RFC 3958, January 2005, and uses NAPTR and SRV resource records (RRs), but with certain restrictions in the flexibility of what is allowed in the NAPTR RRs. FIG. 2 shows an exemplary NAPTR RR obeying the S-NAPTR restrictions, where the flags are restricted to the “a”, “s” or “ ” (no flag) flags and the regexp field is unused (i.e. it is empty). The values of the order and pref fields are merely examples. A RR includes an FQDN that is built up by multiple labels separated by dots (e.g. foo.example.com). The “< >” characters are often used to indicate a generic FQDN or label format in which the expressions within the brackets are supposed to be replaced by some real value/expression in order to form a specific (usable) FQDN/label. Using this notation, a generic expression for a three-label FQDN could be <label1>.<label2>.<top-domain-label>.
In this context, S-NAPTR is utilized to indicate SGWs/PGWs which match the present selection case, e.g. in terms of supported APN, supported mobility protocol, support of the current location (Tracking Area) and/or topological closeness. This information is stored in NAPTR resource records (RRs) in the DNS server(s):                TAI→SGW mapping: The TAI is encoded in the field matching the FQDN in the query in the form of two labels for the TAC (one for the low byte, tac-lb<TAC low byte>, and one for the high byte, tac-hb<TAC high byte>) to the left of the label “tac” in an FQDN ending with: epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org (which thus includes the PLMN ID which complements the TAC into a TAI).        An example could be: tac-lb231.tac-hb14.tac.epc.mnc2.mcc46.3gppnetwork.org        Supported mobility protocol→SGW/PGW mapping: The supported mobility protocol may be encoded in the service field.        Supported APN→PGW mapping: The APN is encoded in the field matching the FQDN in the query in the form of multiple labels, the rightmost of which should be “apn”, in an FQDN ending with epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org, for example: internet.apn.epc.mnc2.mcc46.3gppnetwork.org or, generically, <apn-label-1>.[ . . . <<apn-label-n>.]apn.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org).        Topological closeness: The topological information may be encoded in the FQDNs in the replacement field in the form of multiple labels constituting the “node name”. By comparing the node names of two different GWs (typically a SGW and a PGW), the MME may infer the relative topological closeness of the nodes from the number of consecutive identical labels (starting with the rightmost node name label)—the more identical labels, the closer the two nodes. Appending the label “topon” as the leftmost label indicates that topologically significant information has been encoded in the node name labels. A node name is canonical in the sense that it should be the same for all interfaces of a node (in case the node is multi-homed). Multiple (non-equivalent) interfaces of the same node, allocated for different services or connected to different networks, are distinguished by the first label to the left of the node name.        
FIG. 3 illustrates at a high level the DNS lookup procedure performed within the EPC including initial exchanges to identify suitable SGW(s) and PDN(S) and subsequent exchanges to obtain IP addresses for the selected SGW(s) and PDN(s).
To let all of the above information impact the SGW/PGW selection, multiple NAPTR RRs have to be retrieved, corresponding to multiple DNS queries. However, the DNS mechanisms contain optimizations that drastically reduce the number of DNS queries required in practice. DNS servers send “additional section” information in their replies, which attempt to foresee and preclude subsequent requests and, in addition, DNS clients cache received DNS replies (although no longer than the lifetime indicated in the reply), which eliminates the majority of the queries. Nevertheless, even though most of the DNS queries are avoided, a series of FQDNs (corresponding to potential queries) are involved in the procedure from the FQDN in the initial query to the FQDN in the finally returned A/AAAA resource record. The structure of the initial (input) FQDN and final (output) are specified by 3GPP, but the (arbitrary number of) intermediate FQDNs are left entirely to each operator to use in any way they assess beneficial, e.g. to encode other SGW/PGW properties which may be useful in the SGW/PGW selection process.
The above described DNS assisted SGW/PGW selection mechanism has several deficiencies in terms of path optimization (i.e. SGW/PGW selection based on topological information):                The node name label matching principle provides only coarse topology information.                    For instance, nodes on the same “hierarchical level” (i.e. with equally many matching labels) cannot be distinguished in terms of topological closeness.                        “Border” problems cause problems for the node name matching principle.                    E.g. a node located close to the border of an area represented by a domain name (i.e. a subset sequence of node name labels) may be closer to a node in the neighbouring area than to nodes in the same area (e.g. a node close to the eastern border of “area-west” may have its closest neighbour gateway in “area-east” rather than in “area-west”).                        The node name matching principle provides only relative information, that is no quantitative information.                    As a consequence it is difficult to compare the significance of the topological closeness with other selection criteria when comparing the properties of different SGW/PGW candidates.                        The node name matching principle considers only the SGW-PGW part of the complete PDN connection path. No information is provided on the SeGW-SGW part and the PGW-ASBR part.        The Tracking Area structure and the network topology are designed based on different criteria and requirements (e.g. minimizing signalling and interference based on mobility statistics vs. traffic engineering considerations), which makes it difficult (and even potentially impossible) to unambiguously map a TAI to the topologically closest SGW.        
Similar issues may arise in existing, 3G UMTS core networks, where the Serving GPRS Support Node, SGSN, acts as a mobility management control entity as well as a user plane node (to be allocated to a connection). The Gateway GPRS Support Node, GGSN, is a further user plane node allocated to a connection by the SGSN acting as mobility management control entity.
A possible solution to this problem is to let the MME retrieve the route metrics for the inter-ON node routes by querying the CN nodes and the transport network routers through their operation and maintenance (O&M) interfaces. This solution is however associated with a number of administrational, practical and technical problems.